Forgejo/Gitea as a git provider, configurable per repository - #161

…JO_* names

Testing against a real instance (Forgejo 16.0.0+gitea-1.22.0) surfaced two gaps.

Credential leak. A configured instance now scopes its token to that host. The
normal way to configure one instance is a single global FORGEJO_ACCESS_TOKEN, and
the previous code attached it to EVERY non-GitHub remote -- so opening any public
Gitea/Forgejo repo would have sent an internal token to a third party. A foreign
host is still queried, just unauthenticated, which is correct for a public repo.
Matching is on hostname only: an scp-form remote cannot express the API's port,
so counting scheme/port/path would make the override never apply.

Env names. The provider now reads FORGEJO_BASE_URL and FORGEJO_ACCESS_TOKEN, the
names tea/fgj users and Forgejo's own docs already use, alongside the MAKIT_*
ones it invented.

Verified end to end against a live instance -- branch->PR lookup, draft detection
from a real WIP: title, openPrs ordering, and every mutation:
  - 'ready' stripped the prefix and cleared draft, and refused on a second call
    rather than corrupting the title
  - 'update-branch' and 'merge-squash' both applied; REST reported
    state=closed + merged=true, which maps to MERGED, not CLOSED
  - a codeberg.org repo resolved unauthenticated in the same process, proving the
    token stayed home

… 429

Two defects that only showed up once someone asked whether Forgejo has rate
limits. It does not -- no /rate_limit endpoint, no rate-limit headers, and no
limiter in the whole config surface (its `quota` feature meters storage bytes) --
and both bugs came from assuming otherwise.

1. Forgejo repos were polled 6x slower than needed. The poll cadence came from
   decide(gateway.budget()), and the router forwards budget() to the gh gateway.
   With no GitHub repo the rate_limit read never succeeds, the level stays
   `unknown`, and policy.ts treats unknown as the warm rung: 30s and shed. So a
   quota that provably does not exist was throttling Forgejo polling.

   The router now reports which providers it has actually routed to, and the
   cadence takes the fast rung when the mix is known and excludes GitHub. An
   empty mix stays conservative -- "not yet known" is not "no GitHub", and
   guessing fast would spend GitHub quota for the first ticks after startup.

   Mixed setups still take the GitHub cadence for everything; pr_watcher runs one
   global timer, and taking the fast rung there would burn the quota the ladder
   exists to protect. Documented rather than fudged.

2. No backoff on 429/503. Forgejo core cannot send them, but an instance behind
   nginx limit_req or Cloudflare can, and we answered by polling at the same rate
   -- leaning on a server that had just asked us to stop. The provider now reads
   Retry-After (delta-seconds or HTTP date), caps it at 5 minutes so a bad header
   cannot silently disable polling for a day, withholds background polls while
   waiting without inflating the exec count, still lets interactive calls through,
   and reports `throttled` rather than `none` so a pause never erases a PR pill.

Verified through the real router: mix=[] -> 30s, mix=[forgejo] -> 5s,
mix=[forgejo,github] -> 30s.

…e hostname

Routing keyed off the hostname alone: github.com meant GitHub, everything else
was ASSUMED to be Forgejo. So a GitLab or Bitbucket remote was polled against a
Forgejo API that does not exist there, failed, and reported `unknown` -- exactly
what a healthy Forgejo instance being unreachable looks like. The user had no way
to tell "makit does not support this forge" from "the network is broken".

Detection uses endpoints, not version-string sniffing, each verified live:

  GET /api/forgejo/v1/version   200 on Forgejo, 404 on Gitea
  GET /api/v1/version           200 + {"version":...} on both; GitLab 302s to
                                its sign-in page
  GET /api/v4/version           401 unauthenticated on gitlab.com -- still proof

Forgejo is probed first: decisive in one call, and it is the case we care about.
github.com is never probed. Results are cached per instance so this never adds a
round trip to the PR hot path, and the probe carries the instance token because a
private instance answers 401 to anonymous callers.

A FAILED detection expires after a minute instead of being cached, so an instance
that was briefly down is not pinned as unsupported until the server restarts --
the failure mode that would have been most annoying to diagnose.

GitLab and unidentifiable forges now route to an unsupported provider that makes
zero requests and, on a mutation, says which forge it cannot talk to. The host is
logged once per process rather than once per poll.

Verified against four real forges: codeberg.org -> forgejo, gitea.com -> gitea,
a self-hosted 16.0.0 -> forgejo, gitlab.com -> gitlab, example.com -> unknown.

Detection landed server-side but nothing shows it, so this proposes the three
places it should and one shape it should not.

Corrects the premise it was asked under. The ask was per-REPO provider setup, but
an API token authenticates an INSTANCE -- the server already enforces that, since
forgejoRefFromRemote withholds a token from any host other than the configured
one. So credentials belong to the instance, and the only genuinely per-repo thing
is an override for when detection is wrong. Per-repo credentials would mean
pasting the same secret once per repository and would fight the host scoping.

Grounded in the real vocabulary rather than invented UI: the chip joins
BranchChip/DiffChip/PrStatusChip in repo_chips.dart at kPillIconSize=11, the
override entry goes in the dotsThree menu that already exists at
repo_card.dart:188 beside its themedMenuItem entries, and the state table uses
ForgeSoftwareName verbatim. The Forgejo and Gitea glyphs are the ones actually
drawn in phosphor_extras, inlined on their 256 grid at stroke 16 (which matches
1.45/24 optically).

Two states are listed for `unknown` on purpose: a failed probe expires after 60s,
so "we could not tell yet" must not render the same as "we asked and it is not
supported".

Verified in a browser at 1340x1000: no wrapped grids, no broken glyph refs, no
horizontal overflow, every card read as an image. The prose column is explicitly
its own full-width row -- a 320px phone plus a 560px mac window plus prose cannot
share 1292px, and letting that wrap by accident is what silently hides a column.

…problem

Proposes Settings > Repositories > one repo as the surface for the growing
per-repo set (logo, root path, provider, default branch, worktree root, lifecycle
scripts), grounded in what already exists rather than a new pattern:

  - SettingsGroup / SettingsSectionHeader / SettingsResetButton already ARE the
    grouped-list-with-revert idiom, and SettingsResetButton already collapses to a
    fixed-width box so rows with and without an override stay aligned. That is the
    whole inheritance affordance, built for SPEC-19.
  - project-store.ts already persists one record per project to
    $MAKIT_HOME/projects.json, server-side, degrading to an empty list on a
    corrupt file. Per-repo settings belong there, NOT in SharedPreferences: the
    daemon needs them, and app-side prefs are per-device, so a worktree root set
    on a phone would never reach the daemon that creates the worktree.
  - MAKIT_WORKTREE_DIR (git.ts:33) is a live example of the problem -- a setting
    that is global-only today and wants to be per-repo with inheritance.

The inheritance model is the load-bearing part: always render the EFFECTIVE value
with a badge naming its source, never an empty field that silently means a
default. Reverting means "inherit again", not "copy today's global", so a later
change to the global still propagates.

Flags two blocking security decisions about lifecycle scripts, both unrecoverable
by a later patch:

  1. Script text must live in makit's own config, never be read from the
     repository working tree. Otherwise cloning a repo and adding it to makit is
     arbitrary code execution, and reviewing a stranger's PR branch runs their
     script.
  2. Only the host may set one. makit pairs with phones; if any paired device can
     write a script the daemon executes, pairing stops meaning "chat with an
     agent" and starts meaning "remote shell on my laptop".

Plus the unglamorous parts that decide whether this is safe in practice: an
allowlisted environment rather than the daemon's own (which holds
FORGEJO_ACCESS_TOKEN), a timeout, and pre-prune holding the veto because prune is
the destructive verb.

Build order is deliberately storage-first (rows 1-3, no UI, no security surface,
and it fixes the worktree-root wart immediately) with the hook runner last.

Verified in a browser at 1340x1000: no wrapped grids, no broken glyph refs, no
horizontal overflow, every card read as an image.

The first draft invented chrome. Corrected against a screenshot of the shipped
Settings window:

  - Group headers are GREEN uppercase, not grey, and there is a green uppercase
    PAGE title above them ("SERVER & DEVICES" in the real one).
  - The window has its own chrome: traffic lights, an "X Settings" title and a
    search field above the sidebar -- it is not a bare pane.
  - The sidebar is ~250pt with nine entries (General, Appearance, Agents & Chat,
    Server & Devices, Notifications, Shortcuts, Advanced, About); the selected one
    is a filled rounded rect with green icon and label. "Repositories" is proposed
    after "Agents & Chat", since both concern work content while Server & Devices
    is infrastructure.
  - Rows are two-line (title + grey subtitle) at ~42-52pt, not the 36pt
    single-line rows drawn before.
  - SettingsResetButton sits at the trailing edge, and in the real UI a
    card-level one appears at the Endpoint card's top-right -- so per-row is right
    for per-repo settings, where each row is its own setting.

Type is enlarged relative to the frame: the real window is ~1400pt wide and
cannot be drawn to scale on this page. Stated in a comment so nobody reads the
proportions as a spec.

Verified: no wrapped grids, no broken glyph refs, no horizontal overflow, and an
explicit assertion that no row's label overruns its value -- which caught "Root
path"'s subtitle colliding with the path before this was committed.

…s page

Agreed and redrawn. Fixed app sections, then a green REPOSITORIES group header,
then one entry per repo carrying its monogram -- the Mail/Finder sidebar idiom.

What makes it safe rather than a sidebar that turns into a file browser: the
group is bounded by what the user added. Projects restored from projects.json are
pinned:true (manager.ts:215) while repos makit merely noticed via addProject are
pinned:false (manager.ts:287), so only the former get a section. A real install
holds three (makit, Diana, piano).

Grouping matters. Fixed app sections are a closed taxonomy and repos are data;
interleaving them in one flat list is a smell, but under a header it is a pattern
every macOS sidebar already uses.

It also simplifies the pane: the green page title becomes the repo name, so the
"All repositories >" breadcrumb the previous draft needed disappears.

Names the risk rather than hiding it -- the sidebar becomes a SECOND place
listing repositories alongside the repo-centric home, and two lists drift. The
mitigation is a shared source (same RepoDTO, same monogram widget), not a
convention.

Overflow deliberately unbuilt: past ~10 repos, keep pinned ones inline and add a
single "All repositories..." entry. Cheap to add later precisely because `pinned`
already exists, and three sections is not a scrolling problem today.

Verified: no wrapped grids, no broken glyph refs, no horizontal overflow, no
label/value collisions, div tags balanced.

One Settings section per repository, under a REPOSITORIES group header. The
inheritance model is the feature; the four rows are its first tenants.

UI-first per the request, and it is not a fake: every P1 row has a real source
(monogram from RepoDTO.name, path and defaultBranch already on the DTO, forge from
the detection that already shipped, worktree root from the value git.ts:33 already
computes). The one row without a P1 source -- branch prefix -- is deferred rather
than rendered dead.

15 locked decisions. The two that matter most are D13(a) and (b): script text must
never be read from the repository working tree, and only the host may set one.
Neither is recoverable by a later patch, so P3 is gated on confirming both.

Dispatched for second opinion to two parallel codex reviews (technical correctness
vs engineering practice) before any code.

Recorded rather than quietly patched. Eleven rev-1 claims were confirmed wrong by
hand before being accepted:

- The wire-contract RED test was VACUOUS. contract.test.ts loads snapshots as
  Record<string,unknown> and only asserts codec round-trip; decodeFrame validates
  v/t/id then casts. A new RepoDTO field could never fail it.
- createForgeRouter keeps no per-repo forge decision -- chosen is
  Map<string, Promise<ForgeGateway>> and nothing else.
- repo_service.ts cannot reach the router: it takes GithubGateway.
- The Settings sidebar is a STATIC list carrying search entries, with settings
  open state as a bare bool and no way to carry a repoId. Dynamic per-repo
  sections are foundational work, not an implementation detail.
- RepoCard is the MOBILE home card; the entry-point task targeted the wrong shell.
- git.ts:33 is only the env read; the resolved root is also consumed by
  addWorktree, addWorktreeForPr and uniqueWorktreeDir.

And one finding that changes the product, not the plan: write authorization was
specified for scripts and nothing else. A paired device that can set an arbitrary
worktreeRoot directs host filesystem operations at a path of its choosing.

Two decisions now block rev 2: phasing (a read-only P1 is arguably ornamental vs
the explicit UI-first request) and write authorization for non-script settings.

…rs corrected

Phasing: UI first PLUS one editable row (worktree root end-to-end), so the page
does one real thing on day one and the reviewer's 'ornamental' objection goes away
without abandoning the requested sequencing.

Write authorization: host-only, and enforceable today rather than aspirational --
WsClient.isLocal (ws/client.ts:46) is set from the real socket address in
server.ts:733 and ALREADY gates a privileged input, the app's reported pid in
hello (SPEC-37 D6). Per-repo writes take the same shape: any device reads, only
loopback writes.

Foundations the review exposed are now P0, not assumptions: the router keeps a
per-repo forge decision (it kept none), repo_service gets a narrow ForgeInspector
port rather than the router (listRepos only sees GithubGateway), settings survive
load/save/DTO-copy losslessly (all three dropped them), sectionsFor(repos)
replaces the static registry, and settings open state carries a target id.

Every red test now asserts a value production code must produce. The vacuous one
is replaced by building a repos.snapshot through listRepos and asserting it typed
as RepoDTO[]; T2 asserts all three worktree-root consumers, which is the test that
proves rev 1's 'only consumer' claim wrong.

Cut: provider override in any phase, the four-level chain (there is no global
store), the copy button, blanket two-line rows, hue-determinism as a requirement,
P4, and pixel-perfect as an acceptance gate.

Round 2 returned 9/11 FIXED, both blocking decisions FIXED, and four new errors.
All four applied:

- T3 contradicted itself: ~/x/../../etc is NOT absolute, so it can never be
  'rejected after canonicalisation' -- the absolute check rejects it first. Each
  path case now reaches a different rule, with an absolute ..-containing path for
  the collapse rule and a real symlink for the escape rule.
- D17 said 'canonicalise with realpath' but realpath FAILS on a path that does not
  exist -- so it would have rejected ~/work/worktrees before the user created it,
  which is the common case. Now: canonicalise the nearest existing ancestor, then
  require the remaining segments to be ..-free and symlink-free.
- F4 omitted settings_nav_pane.dart, which calls searchSettings() and builds
  result titles from the static list. Without it repo rows are unsearchable and
  render as repo:<id>. Now covered, with the search title asserted.
- T6 left the integration harness undecided. Decided: mount SettingsWindow with a
  stubbed snapshot, not an extension of the control socket -- the daemon-side
  behaviour it would duplicate is already proven by T2/T3.

…rding verbatim)

Round 3 was scoped to the four fixes only: 2 FIXED, 2 PARTIAL, 1 contradiction.

- T3: 'rejected after collapsing' was still wrong -- collapsing .. yields a valid
  path. A .. segment is now rejected ON SIGHT by a pre-canonicalisation check, so
  the rule cannot silently resolve to something the user did not type.
- D17: added the missing branch -- if no existing ancestor can be realpathed,
  reject. Ancestor symlinks were already covered by realpath, and read-back
  revalidation is what closes the write-to-use TOCTOU window.
- The risk table still claimed the integration harness was undecided, contradicting
  T6.2's explicit choice. Replaced with the real residual risk: SettingsWindow
  needs a stubbed snapshot, which settings_window_test.dart:109 shows is a
  ProviderScope override rather than new infrastructure.

F4 and T6 came back FIXED. All three remaining items were wording the reviewer
dictated, transcribed rather than interpreted.

… real macOS app

The SPEC-48 T4 widget, built from the shipped settings atoms (SettingsSectionHeader,
SettingsGroup, SettingsResetButton, TagChip) so it inherits the window's spacing,
the green uppercase headers, and the reset button's fixed-width collapse.

Takes a RepoSettingsView rather than a RepoInfo: the section shows facts the DTO
does not carry yet (detected forge, EFFECTIVE worktree root, whether it was
overridden), so the widget is complete and testable before the server plumbing
lands -- and it stays pure presentation, told facts rather than deriving them,
which is the rule that stopped the app re-deriving the forge from a PR URL.

Two defects found by screenshotting the real app, not by reading code:

1. The badge column stepped between groups. The Worktree root row reserves a
   SettingsResetButton slot (40pt when hidden) and the Identity rows did not, so
   "inherited" sat 40pt left of "from name" / "detected" / "from remote". Every row
   now reserves the slot, giving the section one right edge -- which is what the
   plan said and what the first implementation did not do.

2. The Git provider row never named the forge. It showed a 20pt glyph, the host and
   a "detected" badge, leaving "detected as WHAT?" answerable only by recognising
   the mark. It now reads "Forgejo - host - token set".

Harness: app/tool/repo_settings_demo.dart, following tool/pr_bar_demo.dart -- real
widget, real theme, seeded states including the two that must render NOTHING (an
unprobed repo omits the provider row; a non-loopback client gets no controls).
Captured with cua-driver window-bound zoom, tiled at scale 1.0 after verifying the
running bundle was not the stale lib/main.dart one.

…e built app

Split decision applied: take the mockup's value column, keep the app's TagChip
badges, drop the descriptive subtitles.

The value column earns it -- a column of right-aligned values scans in one
vertical sweep where values buried in subtitles must be read line by line. It does
mean this row style diverges from CLI/Fingerprint in Server & Devices, which put
their value in the subtitle; that is now a recorded, deliberate divergence rather
than an accident. A subtitle survives only where there is a SECOND fact worth
showing (the forge's host), never as a description of the row -- "Monogram from
the name" under a row labelled "Logo" is words about words.

Paths render home-abbreviated (~/Work/XDent/Diana): a settings row should not spend
40pt of its value column on a home directory the reader already knows. Values are
width-bounded so a long path elides instead of shoving the badge off the row --
the same failure the mockup hit before its subtitle was shortened.

Verified on the real macOS app, both states:
- inherited  -> grey "inherited" badge, reset slot reserved but invisible
- overridden -> green "overridden" badge AND the reset button visible

The overridden state was reached by flipping the harness default rather than by
synthesized clicks: cua-driver reported the sidebar click "unverifiable" and the
scene did not change, so a deterministic default beats spending the user's
foreground on an unreliable input path.

mockups/repo-settings.html card 1 is corrected to match what was built, so the
design board stops disagreeing with the app, and the cut Lifecycle Scripts group is
no longer advertised in either frame.

…table

Requested after seeing the built section. This reverses two locked decisions and
re-opens two cuts from review round 1, so each is justified by the concrete failure
case the reviewer said was missing rather than by the request alone:

- Provider selector (Auto | Forgejo | Gitea | GitHub, the Endpoint idiom): round 1
  cut an override for having "no concrete failure case". There are two -- a private
  instance answering 401 to an anonymous probe, and a proxy hiding
  /api/forgejo/v1/version. Both leave the repo routed to the unsupported provider
  and unusable with no recourse anywhere in the product.
- Root path: "remove and re-add" mints a new PersistedProject.id and loses
  everything keyed to it. A repo that merely MOVED should keep its identity.
- Default branch: origin/HEAD is genuinely absent after a --single-branch clone or
  a rename, and makit then shows the wrong base, so diff-vs-default and the PR base
  are both wrong. Picked from known branches, never free text.
- Logo: two names hashing to the same hue are indistinguishable in the sidebar,
  defeating the one thing the monogram exists for. Palette choice needs no byte
  transfer, so the deferred custom-image path stays deferred.

D16 still governs: only a loopback client may write. A non-loopback view renders the
same values with the selector inert and one line saying where they are editable --
asserted by test.

15 widget tests, two proven to bite by reverting the read-only gate and by making
reset freeze the detected forge instead of asking for Auto.

Interaction is covered by widget test rather than on the real app, and that is a
stated gap: cua-driver synthesized clicks did not land in this Flutter app on two
separate builds -- a sidebar row and a 107x28pt segment both returned
"effect":"unverifiable" and left the UI unchanged. The real-app pass covers
appearance only, which it did verify, including the segmented control and the
Auto subtitle naming what it resolved to.

"from name" beside a monogram, "from remote" beside main, and "detected" beside a
subtitle already reading "Auto: Forgejo - ..." are each the same sentence twice --
and once every row became editable, where a value came from stopped being
actionable. The copy button goes with them: copying a path is not a configuration
task, which review round 1 said before it was overruled.

One rule now, stated in the widget: a badge appears only where nothing else in the
row says it. So exactly one survives -- inherited/overridden on Worktree root, the
only row with no subtitle, where the distinction is the entire point of the
feature. The reset button stays wherever an override exists, because it is an
action rather than a label.

This finishes a cut review round 1 asked for ("they are not one abstraction") and
rev 2 only half-applied by keeping both badge families.

Pinned by two negative tests so the chrome cannot creep back: one asserting the
three provenance labels and the copy tooltip are absent, and one asserting that
with TWO things overridden there are two reset buttons but exactly ONE badge.

17 widget tests green. Verified on the real macOS app; mockups/repo-settings.html
updated in both frames plus its inheritance table, so the board still matches.

Auto | None | Forgejo | Gitea | GitHub. None means makit talks to no forge for this
repository and stops checking pull requests.

It answers two cases nothing else could, and which previously read identically:

- A purely local repo with no origin. It rendered "Auto: not identified yet",
  implying a probe was pending when none can ever help -- and the router still
  sends it to the gh gateway, which fails on every poll. It now reads "Auto: no
  remote, so no forge" with a prohibit glyph: a conclusion, not a wait.
- A mirror or vendored copy whose forge you do not care about. There was no way to
  stop the PR chatter; None is that instruction.

"We could not tell" and "there is nothing to tell" must not read the same, because
only the first is worth investigating. Pinned by a test asserting the two subtitles
differ and that the pending one is absent when there is no remote.

Adds one DTO fact, hasRemote, which the server already computes in the routing path
and currently throws away. P2's write set is now five.

23 widget tests green. Verified on the real macOS app, including the None state's
prohibit glyph, its wording, and the reset back to Auto. Also fixes a harness bug
the screenshot caught: the demo fell back to ForgeChoice.auto rather than the
scene's own choice, so the scene that exists to show an override rendered as if it
had none.

… host-only writes

The server half of SPEC-48. Settings are real: stored, resolved, validated, served
on the wire, and they change where worktrees are created.

repo_settings.ts is the whole model in one place:
  - RepoSettings, every field optional because ABSENT MEANS INHERIT. A blank
    worktree root that silently means ~/.worktrees is how worktrees end up
    somewhere the user did not expect.
  - resolveWorktreeRoot returns the effective value AND its source, so the UI
    labels rather than guesses. Three levels (override -> env -> default), not
    four: there is no global store to inherit from.
  - validateWorktreeRoot, whose rules run in an order that matters. Absolute only.
    A `..` segment rejected ON SIGHT rather than collapsed, because collapsing
    silently yields a path the user did not type -- and prune deletes under this
    root. Canonicalised through the nearest EXISTING ancestor, since a root that
    does not exist yet is the common case and realpath fails outright on it.
    Confined to $HOME, because the daemon creates and removes directories there.

Two bugs found while testing it, both invisible without a test that could fail:
  - The `..` check was DEAD CODE: it split a normalised copy, and normalize()
    collapses `..`. My own test could not catch it either, because path.join
    collapses too -- the case only became reachable once the test built the string
    by concatenation.
  - A test expectation, not the code: macOS /var is a symlink to /private/var, so
    canonicalisation legitimately rewrites the path. That is the rule working.

Wiring: SessionManager.worktreeRootFor is the ONE place all three consumers read
from -- addWorktree, addWorktreeForPr and uniqueWorktreeDir. Reviewer finding R5
was that routing fewer than three makes collision detection disagree with
creation; proven by a test that makes a name collide under the OVERRIDE only, and
which fails when uniqueWorktreeDir is pointed back at the global root.

repo.settings.set is host-only, enforced against WsClient.isLocal on the server --
not a UI convention. Precedent: SPEC-37 D6 already refuses a non-loopback client's
reported pid. A refusal is an explicit error, never a silent no-op. One bad field
rejects the whole patch; null clears a key, which is how the UI says "inherit
again" without a sentinel.

Persistence is lossless, including keys this build does not know: project-store
and the manager both carried only {id, path} and would have dropped a newer app's
field. An untouched project still writes exactly two keys, so the file stays
diffable.

1415 server tests green (+34), typecheck clean. Bites verified by reverting the
loopback gate, the override lookup, and the collision-check root.

RepoInfo gains settings: effective values with their sources, decoded defensively.
An unrecognised source reads as the default and an unknown provider falls back to
auto, so a newer server cannot crash an older app's settings page.

repoSettingsViewFor is the one mapping from wire facts to rendered facts, which is
where "the app is told, never derives" is actually enforced:

- No settings on the DTO yields NO view, rather than a page of fabricated
  defaults. An older server renders nothing, which is honest.
- environment-sourced values are not overrides, so they offer no reset the app
  could not honour -- it cannot change the daemon's environment.
- gitlab/unknown map to no glyph rather than a wrong one; the host still shows so
  the row can name what it cannot talk to.
- "no remote" and "not detected yet" stay distinct all the way through, because
  only one of them is worth investigating.
- Branches are offered from the repo's own worktrees plus its default, deduped and
  sorted, so a pick cannot be a typo.

11 mapping tests + the 23 widget tests, all green. analyze clean.

The settings taxonomy becomes a function of the repo list. kSettingsSections was a
static `final List` resolved statically by SettingsWindow, so a per-repo section was
impossible -- which review round 1 caught and rev 1 had assumed away.

sectionsFor(repos) appends one section per PINNED repo, ids keyed `repo:<projectId>`
off the persisted id so a renamed or moved repo keeps its section. Unpinned repos
stay out: that filter is what stops the sidebar growing into a file browser.

Threaded through both places that read the static list, not just the obvious one.
The nav pane's SEARCH was the subtle one: generated repo items existed but were
unreachable, which looks identical to not generating them. Now covered by a widget
test that fails when the pane falls back to the static list -- analyze does not
catch it, because `sections` is still used for the titles.

RepositorySettingsPage does the writes fire-and-forget with NO optimistic local
state: the server persists, re-broadcasts, and the page re-renders from that. So a
write refused because the client is not on loopback cannot leave the UI showing a
value the daemon rejected.

Root path deliberately shows a notice instead of an edit. Re-pointing a project
needs the daemon to re-check it is a git repo and re-run detection, and getting that
wrong silently detaches a project from its sessions.

Worktree root is a dialog whose value is NOT validated in Dart: the server owns the
rules (absolute, no `..`, inside $HOME, canonicalised) and a second implementation
could disagree with the first.

66 settings tests green, analyze clean. Bites verified on the pinned filter and the
nav-pane search threading.

Records what shipped, and the probe that proved the setting actually moves where
git worktree add writes: two real repos, a real projects.json, a real
SessionManager, and a real worktree landing under the override rather than under
~/.worktrees. No unit test can establish that.

Also records the limitation the probe exposed: it reloaded settings from the file
rather than restarting the process, so the forge field's behaviour across a true
restart -- which would also re-run detection -- is still unproven.

Plan status updated, including the two items honestly marked not-done: the deep
link carrying repoId (F5) and the repo-card entry point (T5) are deferred, since
sections are already reachable from the sidebar, and the integration test is
outstanding.

D3" was only half-shipped: the choice persisted and displayed, but the router
ignored it, so a repo detection could not identify stayed unusable with the
control sitting right next to it. That is the "ornamental setting" failure
review round 1 named.

The override now picks the gateway:

  forgejo/gitea -> the REST gateway, WITHOUT probing. The probe is what fails
                   in both cases the override exists for (a private instance
                   that 401s an anonymous request, one behind a proxy that
                   hides the version endpoint), so spending it would delay
                   every poll to learn nothing.
  github        -> the gh gateway, which is the only way to reach `gh` for a
                   GitHub Enterprise host that is not github.com.
  none          -> a new gateway that talks to no forge and reads no remote.

`none` is deliberately NOT `unsupported`. Unsupported means "we cannot talk to
this forge" and answers `unknown`; None means "do not talk to any forge here"
and answers `none`. `unknown` would make the app hold a stale PR pill and keep
retrying -- the exact chatter None exists to stop. Pinned by a test asserting
the two gateways do not report the same thing.

The routing cache now keys on the choice as well as the path. Without that the
setting would appear to do nothing until the daemon restarted, which is
indistinguishable from a broken feature; an unchanged choice still shares one
`git remote` read, so the home-screen fan-out stays cheap.

Also fixes a bug the DTO carried: `hasRemote` was derived from
`forge !== undefined`, but those two facts have three states between them --
not measured, no remote, a forge -- and one boolean cannot hold three. Every
un-polled repo claimed to have no origin, which made the app's "Auto: not
identified yet" branch unreachable and sent the reader hunting for a missing
remote that was never missing. The router now records the remote as its own
fact (`hasRemoteFor`), undefined until the repo is routed.

Server 1464/1464, typecheck clean. Bites proven by reverting the cache
re-check (only the re-route test fails) and the override branch (six fail).

Stored, served, displayed — and read by nothing. `detectDefaultBranch` was
called directly in three places, so choosing a default branch changed no
behaviour at all. The same mistake R5 caught for the worktree root, in a
setting whose whole justification is that git's answer is sometimes wrong.

One resolver, `resolveDefaultBranch(repoPath, override)`, and all three
consumers read from it:

  - the repos snapshot, whose `defaultBranch` is the base every diff +/- number
    and ahead count is measured against;
  - `createWorktree`, the base a session's branch forks from;
  - `wrapUpWorktree`, the branch it syncs on the way out.

The override is CHECKED, not trusted. It is stored after a syntax check only,
it is picked from branches that existed at the time, and a branch can be
deleted afterwards — so a stale override loses to detection rather than winning
and then failing deep inside a `git diff` where the message is unrecognisable.
Checking costs one `rev-parse` and REPLACES detection's one-to-three calls when
the override holds, so the common path gets cheaper.

The failure it fixes is reproduced in a real repo: `origin/HEAD` still naming
`master` after the default branch was renamed, where git answers with a ref
that no longer resolves locally and the override is the only recourse.

One of these tests was vacuous on the first run and is worth recording: a
branch created from `main` with no commit of its own has the same tip, so
`merge-base` could not tell which branch the worktree forked from and the
assertion held regardless of the production code. The fixture now gives each
branch a divergent commit.

Server 1478/1478, typecheck clean. Both new consumers proven by reverting
their own call site, each failing only its own test.

The third inert write. Picking a hue reached the server, was stored, came back
on the DTO and was parsed into the model — then dropped: `RepoSettingsView` had
no `logoHue` field and the section header built `RepoMonogram(name:)` with no
hue at all. The palette picker changed nothing anywhere.

Worse, the sidebar drew `PhosphorIconsLight.folder` for every repo section, so
all repo rows were identical in exactly the place D14' exists to disambiguate —
and the place the user looks to confirm the colour took. Sections now lead with
the repo's own monogram carrying its chosen hue.

`SettingsSection.leading` is additive rather than a widened `icon`: every app
section is correctly described by a glyph, and `icon` stays required so a
section can never end up with nothing to draw.

Null, not 0, means "no choice": index 0 is a real palette entry, so a numeric
default would silently repaint every repo that never chose.

One test caught itself being vacuous: 'Diana' hashes to palette index 3, so
asserting a chosen hue of 3 differed from the derived one passed for the wrong
reason. It now derives the first index that provably differs, which also
survives a change to the palette or the hash.

flutter analyze clean; the touched suites pass (38 + 10). The 16 whole-file
`loading` failures in the full run are the known app/ harness flake — all four
sampled files pass in isolation.

The last undone P1 task. Every hop was covered in isolation; nothing covered
the composition, which is where this repo has already been bitten: the desktop
shell mounts Settings OUTSIDE a GoRouter, so a section navigating with
`context.go` threw at runtime while every test stayed green. A test that pumps
the section directly cannot catch that class of fault.

Five tests on a real macOS build, over the whole path:

  reposProvider -> sectionsFor() -> nav pane -> RepositorySettingsPage
    -> repoSettingsViewFor() -> RepositorySettingsSection -> the rows

The fixture gives Diana overrides (root, provider, branch, hue) and lets makit
inherit everything, because a fixture where both repos look alike passes even
when the section reads the wrong repo's settings -- which is what the
switch-repos test pins.

Not routed through the daemon control socket, per the plan's T6.2 decision: the
daemon-side behaviour is already proven by the server tests, so the socket would
be infrastructure for no extra coverage. Stubbed at `reposProvider`, the seam
`SettingsWindow` actually reads.

All five bite: making `sectionsFor` ignore the repo list fails every one.

One assertion was wrong on the first run and the code was right --
`SettingsSectionHeader` upper-cases titles, so 'Identity' never matches. Now
asserts the rendered string, plus the row labels, so "the section mounted" can
no longer be mistaken for "the section rendered its contents".

Runner: app/tool/e2e-desktop-settings.sh. flutter analyze clean.

The last of the five writes, and the only one that was not merely inert but
absent: the row showed "not supported yet — remove it and add it again", which
is advice that loses the thing the row exists to preserve. Remove-and-re-add
mints a new `PersistedProject.id`, and everything keyed to it — per-repo
settings, session history — goes with it. Keeping the id across a move is the
entire reason the id exists rather than the path being the key.

`repo.path.set` is a separate command from `repo.settings.set`, not a field in
its patch: it mutates the project record, must re-validate the target is a git
repository, and re-runs forge detection. Folding an async filesystem-and-
subprocess check into a loop that validates plain values would also break that
loop's all-or-nothing property — one bad field would abort a move that had
already happened.

Three refusals, each for an otherwise-silent failure:
  - not a git repo (the constraint D4' names): no branches, no forge, no diff,
    and it presents as broken rather than misconfigured;
  - already another project's path: settings and the forge decision are both
    looked up BY PATH, so two projects at one path answer for each other;
  - anything `validateRepoPath` rejects.

`validateRepoPath` deliberately differs from `validateWorktreeRoot` on two
rules, and a test pins the asymmetry so it cannot be "tidied" into consistency:
the repo path MUST already exist (a repository you have not got is not one, and
accepting it detaches the project from its sessions), and it is NOT confined to
$HOME (that rule protects the worktree root because prune DELETES under it;
makit never deletes a repo path, and a checkout on an external volume is
ordinary).

The router gains `forgetRepo`, kept on its own interface rather than on the
read-only `ForgeInspector`, so detection re-runs against the new path instead of
reporting a stale probe.

A bug the tests caught: the duplicate check compared a canonicalised new path
against un-canonicalised stored ones, so on macOS every /tmp project evaded it
(`/tmp/x` and `/private/tmp/x` are one directory). Both sides are canonical now,
and re-pointing at an equivalent spelling is a no-op that reports the path
actually in force rather than one the store does not hold.

Stated limitation, in the code rather than buried: sessions already bound to a
worktree keep their recorded paths. For the case this exists for, worktrees live
under the worktree root and are unaffected.

Server 1496/1496, typecheck clean; flutter analyze clean; app 27 + 5 e2e green.
Bites proven on the loopback gate and the canonical duplicate check.

Records what P2 closed and, as plainly, what it did not.

The headline: three of P1's five writes changed no behaviour anywhere, and the
fourth row did not exist. That was the "ornamental setting" failure review round
1 named and rev 3 accepted as a risk, so the honest status of P1 was narrower
than "implemented".

Also records the two bugs found while wiring it — `hasRemote` collapsing three
states into a boolean, which made the app's "Auto: not identified yet" branch
unreachable; and a re-point duplicate check comparing paths at different
canonicality — and the two tests that were vacuous until fixed, because a test
that passes while proving nothing is worse than one that fails.

Live proof over a real daemon: 21/21, with the first four assertions covering
the thing no unit test can establish — that the setting changes which provider
serves the repo.

The flow was broken exactly halfway. Listing already routed correctly —
`listOpenPrs` goes through the gateway, so the picker showed Forgejo PRs — and
then the checkout ran `gh pr checkout` unconditionally. `gh` speaks only to
GitHub, so the user saw their PRs, picked one, and the worktree never appeared.

`addWorktreeForPr` now takes a strategy:

  gh        - unchanged for GitHub. Kept rather than replaced with a generic
              equivalent because it already handles fork PRs and sets up push
              tracking; swapping a working path for a hand-rolled one is a
              regression risk taken for tidiness.
  pull-ref  - plain git against `refs/pull/<n>/head`, which is how Gitea and
              Forgejo publish PR heads. That ref exists for EVERY PR including
              forks', which is why it is used instead of the head branch name —
              a fork's branch is not on `origin` at all.

Upstream tracking is set only when the head branch really is on origin (a
same-repo PR), so a push updates the PR. For a fork it is deliberately left
unset: pointing it anywhere would aim a push at a branch that is not the PR's.

`manager.prCheckoutStrategyFor` resolves from the SAME two sources the router
uses to pick a gateway, in the same order — the user's override first, then
routing's decision — so the checkout cannot disagree with the provider that
served the list. Read after `listOpenPrs`, which is what routes the repo, so the
decision is available rather than empty. Unknown falls back to `gh`, the status
quo for an unreadable remote.

Tested against a real local bare repo publishing a real `refs/pull/7/head`, so
the git plumbing is exercised with no network and no forge: the PR's actual
commit is checked out, on a PR-unique branch (the primary checkout commonly sits
on the head ref, and git refuses to check one out twice), a same-repo PR gets its
upstream, a fork PR still checks out without one, and a failed checkout leaves no
litter.

Also pins the GitHub path, which had NO test before this refactor — argv and all,
via a PATH shim. Both bites land: flipping the default to pull-ref fails the gh
tests, and removing the shared rollback fails one test per strategy.

Live probe, end to end over the real commands (`pr.list`,
`worktree.createFromPr`), 12/12: the PR is listed by the Forgejo provider on a
host detection could NOT identify, the strategy resolves to pull-ref, and the
worktree lands at the PR's commit under the repo's own worktree root. Its first
run also confirmed the containment rule works — a worktree root in /tmp was
correctly overruled. Probe deleted.

App side needs nothing: the picker renders `openPrs` with no GitHub gating.

Salvaged from a parallel attempt in this worktree (per user direction) before
removing it: a test that the picker routes per repo with Forgejo and GitHub side
by side in ONE manager, and one that a repo set to None offers no PRs — so the
checkout is unreachable rather than merely moot. Its own two tests reached a
private method through a cast and asserted nothing about routing; its probe did
not compile.

Server 1512/1512, typecheck clean.

Functional correctness
- The Default branch row was rendered only when a branch was already resolved,
  which hid it in exactly the state it exists for: git reports no `origin/HEAD`
  after a `--single-branch` clone or a default-branch rename and no override has
  been set yet, so the user could not reach the picker precisely when they needed
  it. It now always renders, reading `Not detected` — a stated absence rather than
  a blank cell — and stays read-only only when there is genuinely nothing to pick.
- `_tilde` abbreviated any path merely SHARING the home prefix, so with
  `HOME=/Users/le` a repo at `/Users/leduck/x` rendered as `~duck/x`: not a valid
  path, and a different repository. It now requires a separator boundary, and
  `$HOME` itself renders as `~`.
- `forgeKindForUrl` labelled every non-GitHub, non-`gitea.com` host as Forgejo.
  That agreed with the router while the router also guessed by hostname, but the
  router now probes the instance — so the guess could contradict the provider that
  served the data, putting Forgejo's name and mark on a self-hosted Gitea or a
  GitLab remote. An unidentifiable host is now left unnamed (the neutral
  external-link action), which is what this widget's own contract already asked
  for: naming the wrong forge is worse than naming none. It also takes an optional
  `detected` argument — the server's `forge.software` — which wins when supplied,
  so the glyph can be restored properly wherever the repo is in scope.
- When the stored `repo:<id>` section is unavailable the detail pane fell back to
  the first section while `_selectedId` still held the missing id, so the sidebar
  highlighted nothing and the window looked like it had lost its place. The nav
  pane is now told which section is actually shown.

Test correctness
- `/Users/le` was hardcoded in two suites while `_tilde` reads `HOME` at runtime,
  so every abbreviation assertion held on exactly one machine — and one of those
  suites runs on the Linux VM, where it could never hold. Both build their
  fixtures from the real `HOME`.

Harness correctness
- `repo_settings_demo.dart` reconstructed the view from eleven fields and dropped
  `hasRemote` and `logoHue`. `hasRemote` defaults to true, so the "local-only"
  scene — which exists to show `Auto: no remote, so no forge` — rendered
  `Auto: not identified yet`: the harness demonstrated the exact wording it was
  built to check against.
- The default scene was `_scenes.keys.elementAt(5)`, so adding or reordering a
  scene silently changed it and contradicted the comment above it. Keyed by name.

Docs and mockups
- `DEVELOPMENT.md`: state the real detection cache (decisive answers for the
  process lifetime keyed by normalised base URL; `unknown` for 60s then re-probed)
  and that a per-repo provider setting short-circuits probing entirely. Soften the
  Forgejo rate-limit claim to what is verifiable: it exposes no quota to read and
  ships no instance-wide limiter, so limiting comes from whatever sits in front.
- SPEC-48: `ForgeInspector` is `forgeFor`/`hasRemoteFor` in both documents (an
  earlier draft said `softwareFor`, which never existed); D17 names the allowed
  area as `$HOME` and states plainly that read-back validation does NOT close the
  filesystem TOCTOU window, with the residual risk accepted rather than implied
  to be mitigated.
- `forge-detection-display.html`: probes run in sequence with per-probe timeouts,
  not in parallel under one budget; the cache is per host with `unknown`
  re-probed; and the "no settings UI" section is marked superseded.
- `repo-settings.html`: the logo override is a palette index (`logoHue`), not an
  image; the "custom image" state is marked not built; and a stray markdown
  backtick is a `<code>` element like every other identifier in that table.

Also folds in a `TextEditingController` disposal fix for both dialogs that was
already present in the tree, from a parallel agent working in this worktree — it
is correct and analyse-clean, and it was swept into an earlier commit of mine by
`git add -A`. Recorded here so the history is not misleading.

flutter analyze clean; every touched suite green; the 5 macOS integration tests
green. The whole-file `loading` failures in the full run are the known harness
flake — all 26 pass when run together or alone, and the set differs per run.

The pre-push hook's formatter reflowed the lines I touched. Committing its output
so the hook is a no-op rather than something the next push has to fight; `git
diff -w` shows nothing but line wrapping, and the touched suites are green.

Hook formatter output; `git diff -w` is line wrapping only.